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@ Method and apparatus for accessing a relational database without exiting an object-oriented 
environment 

(5?) The method and apparatus of the present 
Invention permit accessing a relational datab- 
ase outside of an object-oriented environment 
without exiting the object-oriented environ- 
ment A requestor object located in the 
object-oriented environment sends a data ac- 
cess message requesting data located in a re- 
lational database outside of the object-oriented 
environment This message is sent to an Inter- 
face which creates a data object containing 
instance variables to hold results from the data 
access request The Interface executes a data 
access routine and the results are placed into 
the data object with the results being sent to the 
requestor object by sending the requestor 
object a pointer to the data object. 
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The present invention relates in general to an 
improved data retrieval system and in particular to a 
method and system for retrieving data from a 
relational database outside of an object-oriented envi- 
ronment Still more particularly, the present Invention 
relates to a method and system for data retrieval with- 
out exiting the object-oriented environment 

Object-oriented languages confer the benefits of 
extendibility and reusable code, but in an object- 
oriented environment, situations exist in which acces- 
sing data in a relational database outside of the 
environment Is desirable. At this point In time, object- 
oriented databases are being researched and 
developed In which an existing relational database is 
redesigned and rewritten as an object-oriented datab- 
ase, but large amounts of data in the modern elec- 
tronic office environment are contained in already 
existing relational databases. In such situations, a 
need may exist to access data In these relational 
databases without exiting the object-oriented environ- 
ment Unfortunately, at the present time no system 
exists in a true object-oriented environment to retrieve 
data from a relational database without exiting the 
environment Presently, individuals working in an ob- 
ject-oriented environment must exit the environment 
to access data using traditional relational database 
access techniques. 

An object in an object-oriented environment is 
consists of related pieces of code and data. An object 
has a library of methods which are essentially unique 
to an object giving an object its specific behaviors. 
The class of an object defines a grouping based on 
one or more properties, and an Instance Is a single 
item in a class. For example, a class of an object could 
be considered as analogous to professions, i.e. 
lawyers doctors, engineers, and programmers, with 
an instance of an object being analogous to a particu- 
lar individual In a class. 

A class defines methods for constructing new 
Instances and also Instance methods which define 
how an instance behaves and reacts to incoming 
messages. The instance variables define the particu- 
lar features of an instance of an object such as an indi- 
vidual's salary. These instance variables may be 
defined or may be empty awaiting definition. An Inst- 
ance's data structure is described by its collection of 
Instance variables. Pointers are used to point to a 
structure in object form. 

SmaIltalk-80 uses a Mod el-View-Controller 
scheme for structuring an application. Model objects 
derive and manipulate data, while view objects are 
responsible for screen presentation and user interac- 
tion. The view objects govern the application flow and 
send messages to model objects to retrieve or modify 
data. The controller manages input and output signals 
from external devices. 

A basic incompatibility exists between object- 
oriented environments and relational databases. Ob- 



ject-oriented environments are rich with pointers 
pointing to data structures, while relational databases 
are flat in organization. The relationships between 
data in object-oriented environments are therefore 

6 built In to the structure of data objects. Since relational 
databases use a flat, table oriented approach to data 
storage, these relationships are not made explicit as 
part of the data storage technique. This makes it dif- 
ficult for data stored in a relational database to be 

10 translated into an object-oriented format 

For example, the Smalltalk V/PM language, a pro- 
duct of Digttalk, Inc., does not support direct access 
to external relational databases. It does, however, 
allow OS/2 Dynamic Unk Library ("DLL") routines to 

15 be invoked and parameters passed to them. Unfortu- 
nately, only a single value may be returned from the 
routine, generally a half word integer or a pointer. 
Since a return must point to a structure in object form, 
this restriction makes it difficult to return multiple col- 

20 umn values for a row and assign them directly into 
instance variables. 

C++ allows retrieval of data from a relational 
database through direct access to a C program, but 
is an extension to C for object-oriented programming. 

25 It adds the structure "class" to C but primarily centers 
on improvements to the C language. C++ Is a hybrid 
language and not a true object-oriented language. In 
C++, the concept of environment is not the same as 
in Smalltalk where every message uses dynamic 

30 binding. 

Therefore, it should be apparent that a method 
and system is needed to access data In a relational 
database without the user having to exit the object- 
oriented environment would be desirable. 

35 It is therefore one object of the present invention 

to provide an improved data access system. 

It is another object of the present invention to pro- 
vide a method and system for accessing data in a 
relational database outside the object-oriented envi- 

40 ronment. 

It is yet another object of the present invention to 
provide a method and system for accessing data in a 
relational database without exiting the object-oriented 
environment 

45 Additional objects, features and advantages wtlJ 
be apparent In the written description which follows. 
The method and apparatus of the present Invention 
permits accessing a relational database outside of an 
object-oriented environment without exiting the ob- 

60 ject-oriented environment A requestor object located 
In the object-oriented environment sends a data 
access message requesting data located In a 
relational database outside of the object-oriented 
environment. This message is sent to an interface 

55 which creates a data object containing instance vari- 
ables to hold results from the data access request 
The interface executes a data access routine that 
accesses data from a relational database and the 
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results are placed into the data object with the results 
being sent to the requestor object by sending the 
requestor object a pointer to the data object 

The novel features characteristic of the invention 
are set forth In the appended claims. The Invention s 
itself however as well as a preferred mode of use, 
further objects and advantages thereof, will best be 
understood by reference to the following detailed des- 
cription of an illustrative embodiment when read in 
conjunction with the accompanying drawings, whe- 10 
rein; 

Figure 1 depicts a pictorial representation of a dis- 
tributed data processing system which may be 
utilized to Implement the method of the present 
invention; 15 
Figure 2 is a diagram depicting the method of ret- 
rieving data from a relational database in accord- 
ance with the method of the present invention; 
and 

Figure 3 is a diagram depicting retrieval of data 20 

from a relational database in Smalltalk V/PM. 

With reference now to the figures, and in particu- 
lar with reference to Figure 1, there is depicted a pic- 
torial representation of a data processing system 8 
which may be utilized to Implement the method of the 25 
present Invention. As may be seen, data processing 
system 8 may Include a plurality of networks, such as 
Local Area Networks (LAN) 10 and 32, each of which 
preferably includes a plurality of individual computers 
12 and 30, respectively. Of course, those skilled in the 30 
art will appreciate that a plurality of Intelligent Work 
Stations (IWS) coupled to a host processor may be 
utilized for each such network. 

As is common in such data processing systems, 
each individual computer may be coupled to a storage 35 
device 14 and/or a printer/output device 16. One or 
more such storage devices 14 may be utilized, in 
accordance with the method of the present Invention, 
to store documents or resource objects which may be 
periodically accessed by any user within data proces- 40 
sing system 6. In a manner well known in the prior art, 
each such document or resource object stored within 
a storage device 14 may be freely interchanged 
throughout data processing system 8 by transferring 
a document to a user at an Individual computer 12 or 45 
32, for example. 

Still referring to Figure 1 , It may be seen that data 
processing network 8 may also include multiple main- 
frame computers, such as mainframe computer 18, 
which may be preferably coupled to Local Area Net- so 
work (LAN) 10 by means of communications link 22. 
Mainframe computer 18 may also be coupled to a 
storage device 20 which may serve as remote storage 
for Local Area Network (LAN) 10. Similarly, Local 
Area Network (LAN) 1 0 may be coupled via communl- 55 
cations link 24 through a subsystem control 
unit/communications controller 28 and communi- 
cations link 34 to a gateway server 28. Gateway ser- 



ver 28 Is preferably an individual computer or Interac- 
tive Work Station (IWS) which serves to link Local 
Area Network (LAN) 32 to Local Area Network (LAN) 
10. 

As discussed above with respect to Local Area 
Network (LAN) 32 and Local Area Network (LAN) 10, 
a plurality of documents or resource objects may be 
stored within storage device 20 and controlled by 
mainframe computer 18, as Resource Manager or 
Library Service for the resource objects thus stored. 
Of course, those skDied in the art will appreciate that 
mainframe computer 18 may be located a great 
geographic distance from Local Area Network (LAN) 
1 0 and similarly Local Area Network (LAN) 10 may be 
located a substantial distance from Local Area Net- 
work (LAN) 32. For example, Local Area Network 
(LAN) 32 may be located in California while Local 
Area Network (LAN) 10 may be located within Texas 
and mainframe computer 18 may be located in New 
York. 

Within the distributed data processing system 8, 
individuals can run different programs on the indivi- 
dual computers 12 and 30 and access other areas of 
the distributed data processing system 8. For 
example, one individual may use an object-oriented 
environment and desire to access a relational datab- 
ase located on a mainframe computer 18 or In storage 
devices 14, 20 in various locations. 

A problem exists with accessing a relational 
database from an object-oriented environment 
because of the difference in the organization and 
structure of data. A specific application Is described 
below as It applies to a particular object-oriented envi- 
ronment 

Referring now to Figure 2, a diagram of a prefer- 
red method for accessing a relational database with- 
out the user having to exit an object-oriented 
environment Is depicted. One object-oriented envi- 
ronment which would be suitable for use with the pre- 
ferred embodiment Is Office vision, a product of 
International Business Machines Corporation. As 
illustrated, a distributed data processing system 8 is 
depicted as including an object-oriented environment 
containing an Address Book window 40. The Address 
Book window 40 is an object within the object-oriented 
environment When a user selects en entries icon 42, 
an Address Book Records window 52 Is opened. The 
Address Book window 52 contains address book 
record entries 54 from a relational database 48. 

The user of the Address Book window 40 does 
not see the interaction between the requestor object 
Address Book Record 46, the Interface object 50, and 
the relational database 48. Address Book Record 46 
is a requestor object that sends a message to get data 
to the interface object 50. The interface object 50 
translates the request into a query that is sent to the 
relational database and receives the query results in 
return. Next the Interface object 50 translates the 
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query results in a format recognizable by the reques- 
tor object Address Book Record 46. The interface 
object 50 passes a pointer, containing the location of 
the requested data, to Address Book Record 46. 
Address Book Record 46 then displays the results 6 
returned from the Interface object 50. 

Figure 3 is a diagram demonstrating a preferred 
embodiment of the invention involving the object- 
oriented language, Smalltalk V/PM, and a relational 
database using structured query language ("SQL"), a 10 
well known language for querying relational datab- 
ases. 

In this embodiment, the interface 50 Is comprised 
of Table Object 63, Translator Object 66, open query 
routine 68, fetch query routine 70, and commit routine 1 5 
72. Table Object 63 creates the data object, and open 
query routine 68, fetch query routine 70, and commit 
routine 72 comprise the data access routines used to 
access the relational database 80 and place data into 
data objects. Each data object preferably corres- 20 
ponds to and contains the data from one row of the 
relational database. The Translator Object 66 con- 
tains Dynamic Link Libraries ("DLL") and makes 
Application Program Interface ("API") calls to the 
appropriate data access routines. 25 

As known In the art, multiple rows of the relational 
database may match a single query. Each row which 
matches the query corresponds to one data object 
Pointers to the data objects are grouped into a collec- 
tion, and Table Object 63 returns a pointer to the col- 30 
lection to the Requestor Object 60. The collection can 
be, for example, an array or a linked list of pointers, 
with the collection being returned by returning a 
pointer to the array or the head of the linked list 

In response to a request by a user, Model Object 35 
60, which is the requestor object in this particular 
embodiment and corresponds to the Address Book 
Record 46 In Figure 2, executes a method, Open 62, 
that Invokes an object, Table Object 63, and sends the 
message, "get Contents' to Table Object 63. 40 

As a result, Table Object 63 creates a data object 
containing instance variables that can be passed to 
the data access routines for assignment of the inst- 
ance variables. The data object created by Table 
Object 63 contains Instance variables in the same 45 
order as the columns from which data Is retrieved by 
the data access routines, open query routine 68, fetch 
query routine 70, commit routine 72. Table Object 63 
executes a method, get Contents 64, that invokes 
Translator Object 66 and sends a message, "open 50 
Query", and passes a parameter or pointer to the data 
object 

Translator Object 66 executes a method, open 
Query 74, that sends an Application Program Inter- 
face f API") call to open Query routine 68 along with 55 
the parameter or pointer to a data object resulting in 
the open Query routine 68 setting up a structured 
query language data area ("SQLDA") and SQLOA 



pointers. The SQLDA is set up by passing a par- 
ameter or starting pointer to the open Query routine 
68 up. The SQLDA basically tells the relational datab- 
ase 80 where to put data. Afterwards, the open Query 
routine 68 sends a message to Translator Object 66 
that the SQLDA and the SQLDA pointers have been 
setup. This message Is sent to Table Object 63 and 
get Contents 64 sends a message, "fetch Query", to 
Translator Object 66. Translator Object 66 invokes a 
method, fetch Query 76, sending an API call to a fetch 
Query routine 70. The fetch Query routine 70 returns 
a row of data to the data object created by Translator 
Object 66. The fetch Query routine 70 preferably Iter- 
ates through the columns of the SQLDA In the same 
order as the data object's instance variables. Table 
Object 63 contains different tables for retrieving diffe- 
rent types of data or data in a different order. Each 
table has a set of data access routines configured to 
retrieve the particular data In the order set by a par- 
ticular table. 

After a data object's instance variables have been 
Tilled, the data object's pointer is added to a collection 
containing pointers to the data objects. The method, 
get Contents 64, continues to loop and invoke Trans- 
lator Object 66 until it receives a message that no 
more data is left to be retrieved. When fetch Query 
routine 76 sends a message to Translator Object 66 
that there is no more data to be retrieved, this mes- 
sage is sent to Table Object 63. 

In response to the no more data message, Trans- 
lator Object 66 sends a message, "commit", to Trans- 
lator Object 66, resulting In the execution of a method, 
commit 78, which sends an API call to a commit 
routine 72, which return closes up the relational 
database 80. Afterwards, Translator Object 66 
receives a message that the relational database 80 
has been closed and relays the message to Table 
Object 63. Finally, the collection of data objects are 
sent to Model Object 60 by sending a pointer to the 
collection to the Model Object 60. 

Table Object 63 may have a plurality of tables, 
each table having a set of data access routines used 
to correctly place data into data objects. For example, 
if the Model Object 60 is an address book and 
requests data In the order last name, first name, and 
telephone number, Table Object 63 will invoke a table 
that calls a set of data access routines that retrieves 
the particular data in the order requested by the Model 
Object 60. If Model Object 60 requests data in the 
order last name, first name, telephone number. Table 
Object 63 would use a second table that Invokes a 
second set of data access routines that retrieves data 
In the requested order. Thus, for changes In the order 
or data retrieved, a different table in the Table Object 
63 and a different set of data access routines are 
used. 

The embodiments presented are merely illustra- 
tive of the Invention and Is not Intended as limitations 



4 



7 



EP0 504 085 A1 



8 



to the invention. For example, in the embodiment illus- 
trated in Figure 3, other .methods of returning the data 
objects to the requestor object may be used in addi- 
tion to returning pointers to the data objects. Further- 
more, the requestor object could create and fill the 
data objects, thus eliminating the need for the Table 
Object 63. Furthermore, Table Object 63 and Trans- 
lator Object 66 could be combined into one object 
under the present invention. 

The data access routines may be made more 
flexible to permit a change in order of data retrieved 
by sending parameters to the data access routines 
directing the routine as to where the data should be 
placed. For example, a data access routine may ret- 
rieve a first name, a second name, and a telephone 
number. The user may desire to have the data in the 
order of last name, first name, telephone number or 
first name, last name, telephone number. Changing 
the order that data Is placed In a data object may be 
accomplished by having a table for each order In the 
Table Object 63. By passing parameters to the data 
access routine, one table in the Table Object 63 would 
cause the first name to be placed first. A second table 
in the Table Object 63 would send a different set of 
parameters causing the last name to be placed first in 
the data object Thus, if the order first name, last 
name, telephone number or desired, then the table 
associated with that particular order would be 
invoked. 

Increased flexibility may also be accomplished by 
using data access routines that retrieves all the col- 
umns In a relational database. By passing parameters 
to the data access routines Indicating which columns 
should be placed in the data object and in what order 
the selected columns should be placed in the data 
object, various combinations of data and ordering can 
be made possible by using different tables in a Table 
Object 63 and one data access routine for a relational 
database. 

For example, a relational database contains 
name, telephone number, and address. Sometimes, 
a user may want to make telephone calls and desire 
only to retrieve a name and a telephone number. 
Other times, a user may be mailing documents and 
desire to retrieve name and address, but not a tele- 
phone number. For each situation, a table in the Tebte 
Object 63 Is used to pass parameters to the data 
access routine, directing the routine as to what data 
is to be placed in the data object and in what order. 
This allows the personalization of data retrieval 
through setting up tables In the Table Object 63 for the 
particular format desired without having to create a 
new set of data access routines. Thus, a single data 
access routine for a particular relational database 
could be used by many users. 

The embodiment illustrated illustrates the reading 
of data, but the present invention may also be used to 
modify data, change, or add data. To modify data 



under the embodiment illustrated in Figure 3, the fetch 
query 76 method would not be needed in Translator 
Object 66, and the open query 74 method would 
include more parameters identifying such information 
5 as what data Is to be changed or added to the 
relational database 80. 



Claims 

to 

1. A data processing system for accessing a 
relational database outside of an object-oriented 
environment without exiting the object-oriented 
environment comprising: 

15 a requestor object in the object-oriented environ- 
ment which sends a data access message; and 
an interface in communication with the requestor 
object in the object-oriented environment and the 
relational database outside of the object-oriented 

20 environment, the interface having a means for 
receiving the data access message from the 
requestor object, accessing the relational datab- 
ase, and returning a result to the requestor object 

25 2. The data processing system of claim 1 wherein a 
data object containing Instance variables holds 
the re suit returned to the requestor object 

3. The data processing system of claim 2 wherein 
30 the data object is created by the interface. 

4. The data processing system of claim 2 wherein 
the data object is sent by the requestor object 
along with the data access message to the inter- 

35 face. 

5. The data processing system of claim 2 wherein 
the data object contains instance variables 
matching columns In the relational database ret- 

40 rleved by a data access routine. 

6. The data processing system of claim 1 wherein 
the interface Includes a data access routine which 
ac cesses the relational database. 

45 

7. The data processing system of claim 2 wherein 
the Interfaces includes a table object which 
creates the data object and fills the instance vari- 
ables with data from the relational database. 

50 

8. The data processing system of claim 6 wherein 
the interface contains a control object which con- 
trols the data access routine. 

55 9. The data processing system of daim 1 wherein 
the requestor object sends a data access mes- 
sage re questing data from the relational datab- 
ase. 
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10. The data processing system of claim 1 wherein 
the requestor object sends a data access mes- 
sage re questing a modification of the relational 
database. 

s 

11. The data processing system of claim 1 wherein 
the Interface returns the data object by sending 
the requestor object a pointer to the data object 

12. The data processing system of daim 1 wherein to 
the interface contains a means for corresponding 

an Instance variable in a data object to a column 
in the relational database. 

13. A method for accessing a relational database out- 15 
side of an object-oriented environment without 
exiting the object-oriented environment compris- 
ing: 

receiving a data access message from a reques- 
tor object In the object-oriented environment; 20 
creating a data object in the object-oriented envi- 
ronment for holding data; 
sending the data access message to a data 
access routine which accesses the relational 
database; 25 
receiving results of the relational database 
access from the data access routine; 
placing the results in the data object and 
sending the data object to the requestor object 

30 

14. The method of claim 15 wherein the sending the 
result step Includes sending the requestor object 
a pointer to the data object. 

1 5. The method of daim 15 wherein the data access 33 
rou tine places the result in the data object 
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